I. Field of the Disclosure
The technology of the disclosure relates generally to flash memory and processing commands for flash memory.
II. Background
Flash memory is common in many sorts of computing devices including mobile terminals such as cameras, audio players, smart phones, tablets, and the like. Flash memory may be one of two general types—removable or embedded—and several standards exist for both general types. One standard initially designed for embedded situations is the Universal Flash Storage (UFS) standard set forth by the Joint Electron Device Engineering Council (JEDEC). Another common standard is the embedded Multi-Media Controller (eMMC) standard.
In the UFS standard, a host communicates with a device that holds the memory elements. The host issues commands to the device to execute “transfer request” tasks such as writing data into the memory elements, reading data from the memory elements, and synchronize cache. By design, UFS supports multiple concurrent transfer requests. The transfer requests are software driven at the controller of the host and use a register called a doorbell register and a software variable referred to (at least within a LINUX implementation) as an outstanding requests variable. While the term “outstanding requests variable” is specific to LINUX, other operating systems use similar variables and all are referred to herein as outstanding requests variables. Each transfer request occupies a slot and a corresponding bit in the doorbell register and the outstanding requests variable. When sending a new transfer request, software sets a bit corresponding to the slot in the register and the variable. Setting the bit in the register notifies the controller that a new transfer request is ready. When a transfer request is completed, the hardware clears the bit corresponding to the slot in the register, and software then compares the bit in the register to the bits in the outstanding requests variable to find completed requests. Note that eMMC is similar, although the particular elements may have different names.
If the host receives an interrupt before setting the doorbell register and after updating the outstanding requests variable, the host may recognize that the request is completed before the request was sent. In such a situation, the software may complete the request, but with an error. Alternatively, if the host receives an interrupt after setting the register and the request was completed before updating the outstanding requests variable, the request may be lost. Still another situation may delay requests until another transfer request completion interrupt arrives. Such situation either delays the request, thereby causing performance degradation, causes the delay to last indefinitely, or until an error occurs which aborts the command. Currently, such situations are avoided through the use of a software lock. However, such software locks are slow and may exclude other transfer requests. Further, such software locks or exclusions generally increase latency resulting in a degradation of performance, especially in multi-core processors.